• The support for "default" arguments in C++ allows you to drop all trailing parameters that are equal to zero:
LONG FORM: FaceIt(0,DoLoop,0,0,0,0);
SHORT FORM: FaceIt(0,DoLoop);
• FaceWare "modules" have interfaces that are very similar to those of C++ classes. We might, for example, have created an application class of type "FaceRec" and one global instance named "fRec" with member functions "DoLoop", "DoInit", DoEvnt", "GetCtl", etc. Function calls and variable references would then appear as follows:
WITH CLASSES: "fRec.DoLoop();" "fRec.uMenuID"
WITHOUT CLASSES: "FaceIt(0,DoLoop);" "fRec.uMenuID"
but, as you can see, there is hardly any advantage in the use of a class in this case. When dealing with controls in ViewIt windows, you might think that a class-based system would definitely be helpful, but, again, our existing interface is quite efficient and easy to use:
WITH CLASSES: "theControl.MovCtl(b,c,d);"
WITHOUT CLASSES: "FaceIt(0,MovCtl,theControl,b,c,d);"
Note that the use of a control-related class would also involve creating and managing an instance of such a class for EACH control, an operation which is completely unnecessary with our existing interface. Further complexities arise if the control class was made to handle control messages via member functions. This would make it much more complicated, for example, to respond to events within a simple dialog if EACH control in the dialog had its own event-handling function (vs. writing a short block of code to handle all messages from the dialog).
Similar results are obtained when dealing with utility-type FaceWare modules. Their "shared records" are equivalent to instances of a class, and their commands are equivalent to member functions of the class. Opening a database file with DocuBase, for example,
"FaceIt(@dbRec,DBNewFil,a,b,c,d);"
might look like this if "dbRec" was an instance of a "DBaseRec"-type class:
"dbRec.DBNewFil(a,b,c,d);"
The lesson to learn from these examples is that the existing interface to FaceWare modules is already quite "object-oriented", so you should not jump to the conclusion that programming will be made much simpler by "wrapping" the FaceWare interface with a class hierarchy.
• "If I don't need classes to work with FaceWare modules, when should classes be used?" You should use classes to model your own program's data and/or operations. You might find it advantageous, for example, to associate a window with a file containing a certain type of data, but the data in the file (and/or how it is to be processed) should be the basis for your class hierarchy, not the ViewIt window or other user interface elements.
